REMARKS/ARGUMENTS 



In the Office Action of September 4, 2008, the Office set forth the following 
rejections: 

a) Claims 1-14, 17-23, 26-28, 30-39 and 41-51 under 35 USC §1 02(b) as being 
anticipated by U.S. 6,389,467 to Eyal (referred to as the Eyal reference); and 

(b) Claims 1 5, 1 6, 24, 25, 29 and 40 under 35 USC §1 03(a) as being 
unpatentable over the Eyal reference in view of U.S. 2003/0236906 to Klemets et al. 
(referred to as the Klemets reference). 

Examiner Interview of November 5, 2008 

An interview was held on November 5, 2008 with Examiners Jakovac and 
Swearingen. Applicant sincerely appreciates the Office's time in this matter. During the 
interview, Applicant discussed how a "media source object" can be a component in a 
media pipeline, for example, as part of a multimedia framework of an operating system. 

Instant Application: Media Source Object for a Media Processing Pipeline 

The Instant Application is entitled "System and Method for Accessing Multimedia 
Content". Specifically, access to content occurs through use of a source object in a 
object-based media processing pipeline (see, e.g., Fig. 2). 

As discussed during the interview, a media source object may be selected via a 
path that does not include a byte stream object or via a path that includes a byte stream 
object. The former is referred to as a media source object path and the latter as a byte- 
source object/media source object path. 

In various examples, a source resolver relies on one or more helper objects to 
ultimately select a media source object (see, e.g., media source object 222 and 
handlers 215 and 21 7 of module 21 4 of Fig. 2). The media source object can be 
provided to an application (e.g., an application in a control layer) and form part of a 
component object-based media pipeline (see, e.g., pipeline 220 of Fig. 2). In various 



19 



examples, a pipeline includes a media source object and a media sink object (see, e.g., 

media source object 222 and media sinks 228). A media source object may access 

media content and generate media data for processing in a pipeline. A media sink 

object may assist in rendering or archiving media content. Some examples are 

described at paragraph [0036] of the Instant Application: 

In general, media sinks are responsible for sending the (possibly 
transformed) multimedia data to wherever or whatever is specified by 
media application 204 in the media content destination 208. For example, 
in a playback application, the destination may indicate a window, and the 
media sinks would be audio and video Tenderers that send the multimedia 
data to devices; in an encoding application, the destination may indicate a 
file to which the encoded bits are to be archived, and the media sinks 
would be responsible for arranging these bits in the appropriate format 
and writing to the file, etc. 

Instant Application at 10036]. 

Eyal Reference: Backend Tier Database w/Table of URLs and Data Type ("DT") 
Summary 

Applicant submits that the Eyal reference is about a search and retrieval 
architecture and system. It does not address "playback" other than indicating that a 
data type ("DT") associated with a URL may be used with a compatible playback 
component (a commercially available playback component per col. 11, lines 1 -2: "Real 
Network Player™, Apple Quicktime Player™, and Microsoft Windows Media Player™"). 

As discussed below, Applicant submits that the Eyal reference fails to provide 
evidence as to selection of an object for use in an object-based pipeline for rendering or 
archiving media content. In other words, use of a commercially available "playback 
component" (e.g., a commercially available player) based on a data type in a table is 
different than selection of a media source object for use in an object-based pipeline. 
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Prior Response 

As stated in the prior response (Response of July 7, 2008), based on a review of 
the evidence in the Eyal reference: "it appears that the system of the Eyal reference 
relies merely on storage of data type with a link in a database and, for protocols, on 
replacing a string portion as to protocol type (e.g., "PNM")". Applicant respectfully 
directs the Office to the prior response for further details as to this finding (citing col. 21 , 
lines 35-46 of the Eyal reference). 



Additional Findings: Database/Table in Context of Principle of Operation 

The Abstract of the Eyal reference states: 

A network enabled device receives search criteria and accesses a 
memory that includes a plurality of network addresses. The memory 
associates each address with one or more classes of information. Each 
address in the memory locates a media network resource. A plurality of 
the addresses are selected using the search criteria. The selected 
addresses are signaled to the network enabled device. A media playback 
component on the network enabled device sequentially plays back the 
media resources provided by at least some of the selected addresses 
automatically. 

Figs. 2 and 4 of the Eyal reference show an "Internet Enabled Multimedia 
Computing Platform" 210 (IEMCP). In Fig. 4, the IEMCP 210 sends a search request 
203 to a "Web Server Module" 270, which, in turn, accesses "Media & Metadata" 247 
that simply has a table 249 that associates URLs with data type ("DT"). The overall 
process for is explained at col. 19, lines 30-54 where the table 249 "includes a URL list 
comprising a plurality of URLs" where "[e]ach URL is characterized by one or more 
parameters that correspond to metadata information about the web resource associated 
with the URL". Applicant respectfully notes that the URL associated metadata 247 (i.e., 
in the "Media Sites Table") of Figs. 2 and 4 are stored in the "Back-end Database 
Management System Module" 245. 

As to the principle of operation of the system of the Eyal reference, Fig. 3 shows 
various components organized in a front tier, a middle tier and a backend tier. At col. 



21 



16, line 55 to col. 18, line 8, the Eyal reference describes the three tiers. This three tier 
model relies on the backend tier's database management system 245, which includes a 
database 345 and a backend interface module 355. Applicant notes that the table 
explicitly shown as 247 in Fig. 4 corresponds to the table 247 of Fig. 2 and would be 
logically stored in the database 345 of Fig. 3. 

In reviewing Figs. 2, 3 and 4 of the Eyal reference, Applicant fails to find 
evidence of selecting a media source object for use in an object-based pipeline. 
Instead, Applicant finds a table stored in a backend tier database where the table 
includes URLs associated with data type ("DT") and where playback occurs using a 
playback component 21 1 suited to the data type. 

With respect to objects, at col. 17, lines 62-64 the Eyal reference states: "The 
component and all tiers expose programmatic interfaces that contain callable methods 
using the MS DCOM (distributed component object model) software component 
technology". However, Applicant finds no evidence of a media source object configured 
to generate data in an object-based pipeline that can render or archive media content. 

Again, Applicant concludes that the Eyal reference merely describes a search 
mechanism that returns media URLs from a table in a remote database. Metadata 
indicating data type ("DT") do not cause or otherwise lead to selection of a media 
source object for use in a object-based pipeline. 

Applicant further submits that the "playback component" 21 1 (A/8: sometimes 
1710) is described as being a commercially available media playback component (see 
col. 11, lines 1-2: "Real Network Player™, Apple Quicktime Player™, and Microsoft 
Windows Media Player™"). At col. 32, lines 51-67, the Eyal reference describes the 
playback component as residing on a user terminal 1710: "Once loaded, the media 
resources are played back by a media playback component on user terminal 1710"; and 
"The URLs are selected for media playback so as to output media from user terminal 
1710 according to a predetermined program". Regarding the latter, "the program is 
selected or defined from a search request of user" (col. 33, lines 1-8). 
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Amendments to the Claims 

Providing Media Source Object to Application 

Applicant currently amends independent claims 1 and 43 to recite providing a 
media source object to an application. Claim 1 recites "receiving a uniform resource 
locator (URL) as associated with one of a plurality of applications requesting media 
content". The various actions recited in claim 1 allow an application to handle (e.g., 
cause rendering or archiving) the requested media content via a media source object. 

Media Source Object for Object-based Pipeline 

Independent claim 1 is currently amended such that the media source object is 
configured "for generating media data in a component object-based pipeline that allows 
for rendering or archiving the media content. Applicant notes that original dependent 
claims 48, 49 and 50 recited a pipeline. 

Independent claim 17 is currently amended to recite a media source object 
"operable to generate data in a component object-based pipeline to allow for rendering 
or archiving the media content'. 

Independent claim 35 is currently amended to recite that a media source object 
"generates data in a component object-based pipeline of the multimedia framework to 
allow for rendering or archiving the media content'. 

Independent claim 43 is currently amended to recite that the media source object 
is "operable to generate data in a component object-based pipeline to allow for 
rendering or archiving the media content'. 

New Independent claim 52 is presented and recites, in part, "providing the 
selected media source object to the one of the plurality of applications executing on the 
operating system of the computing device to thereby allow for a object-based media 
pipeline that comprises the media source object configured to generate media data and 
a media sink object configured to render or archive the media content'. 
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Rejections under §1 02 



Independent Claim 1: Media Source Object for Pipeline 

As currently amended, claim 1 recites: 

A method implemented in a component object-based multimedia 
framework for an operating system executing on a computing device, the 
method comprising: 

receiving a uniform resource locator (URL) as associated with one 
of a plurality of applications requesting media content; 

identifying a scheme associated with the URL; 

selecting a first object operable to handle the identified scheme 
associated with the URL to access parameter data from a location 
specified by the URL; 

based on the accessed parameter data, selecting a second object 
operable to read media content of a given type from the location specified 
by the URL wherein the second object comprises a media source object or 
a byte stream object; 

where if the second object comprises a media source object, 
providing the media source object to the one of the plurality of applications 
for generating media data in a component object-based pipeline that 
allows for rendering or archiving the media content; and 

where if the second object comprises a byte stream object, 
selecting a media source object based in part on the byte stream object 
and providing the selected media source object to the one of the plurality 
of applications for generating media data in a component object-based 
pipeline that allows for rendering or archiving the media content. 

As currently amended, independent claim 1 recites a method (a) implemented in 
a component object-based multimedia framework that can (b) provide a media source 
object to an application for (c) use in a pipeline that provides for rendering or archiving 
media content. 
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Applicant submits that the Eyal reference does not provide evidence sufficient to 
disclose the subject matter of claim 1 . As explained above, Applicant concludes that 
the Eyal reference merely describes a search mechanism that returns media URLs from 
a table in a remote database. Metadata indicating data type ("DT") do not cause or 
otherwise lead to selection of a media source object for use in a object-based pipeline. 

Independent claims 1 7, 35, 43 and 52 

Above, Applicant pointed to subject matter of these claims including a media 
source object and a pipeline that allows for rendering or archiving media content. 
Applicant submits that the Eyal reference does not provide evidence sufficient to 
disclose such subject matter. 

Dependent claims 2-3. 7-14. 18-23. 26-28. 30-34. 36-39. 41 -42 and 44-51 

As these claims depend on a respective one of independent claims 1 , 17, 35 and 
43, Applicant submits that they are not anticipated by the Eyal reference for at least the 
foregoing reasons. Applicant notes that claims 4, 5 and 6 are canceled. 

Rejections under §103 

The Office rejected claims 15, 16, 24, 25, 29 and 40 under 35 USC §1 03(a) as 
being unpatentable over the Eyal reference in view of the Klemets reference. 

Per MPEP §2143: "The key to supporting any rejection under 35 U.S.C. 103 is 
the clear articulation of the reason(s) why the claimed invention would have been 
obvious." "The rationale to support a conclusion that the claim would have been 
obvious is that 'a person of ordinary skill in the art would have been motivated to 
combine the prior art to achieve the claimed invention and that there would have been a 
reasonable expectation of success'." "If any of these findings cannot be made, then this 
rationale cannot be used to support a conclusion that the claim would have been 
obvious to one of ordinary skill in the art." 
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Per MPEP §2143.01 : "If the proposed modification or combination of the prior art 
would change the principle of operation of the prior art invention being modified, then 
the teachings of the references are not sufficient to render the claims prima facie 
obvious". 

Per MPEP §2143.03: "All words in a claim must be considered in judging the 
patentability of that claim against the prior art." "If an independent claim is nonobvious 
under 35 U.S.C. 103, then any claim depending therefrom is nonobvious." 

Above, Applicant provided evidence and argument as to the system of the Eyal 
reference, which relies on a search mechanism that returns media URLs from a table in 
a remote database, which can include metadata indicating data type ("DT"). The 
principle of operation of the system of the Eyal reference associates a commercially 
available media player with a data type. Specifically, the "playback component" 21 1 
(A/6: sometimes 1710) is described as being a commercially available media playback 
component (see col. 1 1 , lines 1-2: "Real Network Player™, Apple Quicktime Player™, 
and Microsoft Windows Media Player™"). 

Applicant submits that all pending claims are patentable over the Eyal reference 
in view of the Klemets reference because Applicant finds insufficient evidence to teach 
or suggest providing a media source object operable in an object-based pipeline. In 
other words, Applicant contends that one of ordinary skill in the art would not be 
motivated to modify the system of the Eyal reference to meet the claimed subject matter 
because there is no evidence of (i) a media source object and (ii) an object-based 
pipeline that relies on the media source object to generate data. 

Further, Applicant submits that if one carried out such a modification, the 
principle of operation would be changed. Per MPEP §2143.01: "If the proposed 
modification or combination of the prior art would change the principle of operation of 
the prior art invention being modified, then the teachings of the references are not 
sufficient to render the claims prima facie obvious". 
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Conclusion 

Applicant submits that, for at least the reasons above, claims 1-3, 7-14, 17-23, 
26-28, 30-39 and 41-52 patentable over the cited references. Applicants therefore 
respectfully request the Examiner's reconsideration and withdrawal of the rejections as 
to the pending claims and an indication of the allowability of same. 

In view of the amendments and remarks set forth herein, the application is 
believed to be in condition for allowance and a notice to that effect is solicited. 
Nonetheless, should any issues remain that might be subject to resolution through a 
telephonic interview, the Examiner is invited to telephone the undersigned attorney. 

Respectfully submitted, 



/Brian Panqrle/ Feb. 4, 2009 
Brian Pangrle Date 
Lee & Hayes, PLLC 
Reg. No. 42,973 
Telephone: (509)-944-4731 
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